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REMARKS 

In the patent application, claims 1-7, 9-17, 19-34 and 36 are pending. In the final office 
action, all pending claims are rejected. 

A. 102 Rejection 

At section 2 of the office action, claims 1-7, 9-17 and 19-34 and 36 are rejected under 35 
U.S.C. 102(e) as being anticipated by Ravi et al (U.S. Patent No. 6,292,834, hereafter referred to 
as Ravi) and Wang et al (U.S. Patent No. 5903,673, hereafter referred to as Wang) incorporated 
by reference. 

The Examiner states that Ravi teaches a method for multimedia streaming as claimed in 
claim 1. 

A. 1 Claim Limitations in Claim 1 

It is respectfully submitted that claim 1 includes the limitations of 

1) defining in a client in a multimedia streaming network at least one parameter for 
determining a rate adaptation operating range, wherein the streaming network comprises a server 
configured for providing streaming data to the client, the client having a receiver buffer for 
storing at least part of the streaming data to compensate for a difference between data 
transmission amount by the server and usage amount of the streaming data by the client so as to 
allow the client to have sufficient amount of streaming data to play out in a non-disruptive 
manner, and wherein the rate adaption operating range is used for rate adaptation between the 
server and the client; 

2) providing to the server information indicative of said at least one parameter; 

3) adapting in the server the data amount to a reception rate at the client based on said at 
least one parameter, and 

4) adjusting in the client packet transfer delay variation based on said adapting, wherein 
the one parameter comprises a shift amount in time indicative of a difference between a sampling 
time and a transmission time of a packet at the server. 
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A.2 Rejection of Claim 1 

In rejecting claim 1, the Examiner points to column 6, lines 33-47; column 7, lines 16-25 
and column 8, lines 26-45 to show that Ravi discloses adapting in the server the data amount to a 
reception rate at the client based on said at least one parameter. The Examiner further points to 
col. 10, lines 1-67 of Wang to show that Ravi, by incorporation by reference, discloses 
transmitting a frame based on network condition, and adjusting the cumulative bandwidth 
balance amount of bandwidth time consumed by current frame. In particular, the second loop 
rate control 204 adds to the cumulative bandwidth and the current frame and subtract from the 
cumulative bandwidth balance the amount of bandwidth time consumed by the current frame. 
Thus, Ravi discloses the difference between a sampling time and transmission time of a packet at 
the server. 

A.2.1 Previous Argument Against Rejection of Claim 1 

The rejection of claim 1 in the final office action is identical to the rejection in the non- 
final office action, mailed June 8, 2009. 

In response to the non-final office action, applicant points out that Wang discloses using a 
Q adjuster 1 16 to adjust the Q 1 14 based on the output of the primary open loop rate control 202 
and the output of the secondary closed loop rate control 204 (Figure 2; col.9, lines 33-43). The 
quantization parameter Q used in encoding will affect the amount of encoded data of a frame 
and, therefore, the cumulative data amount to be transmitted. However, adjusting the cumulative 
data amount to be transmitted is different from changing the sampling time. A sampling time is 
when the packet is started to be sampled relative to when the packet is started to be transmitted, 
for example. The sampling time can be moved up or delayed relative to the transmission time 
without changing the encoding resolution. Likewise, the cumulative data amount of the packet 
can be decreased by changing the quantization parameter Q without changing the sampling time. 

Therefore, Ravi and Wang fails to disclose adjusting a shift amount in time indicative of a 
difference between a sampling time and a transmission time of a packet at the server. 

A.2.2 Examiner's Response to Applicant's Previous Argument 

At section 5 of the final office action, the Examiner states that "According to the present 
application, before transmittal of a stream, the data needs to be encoded by the server. The rate 
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of encoding is called a sampling rate" (page 8, lines 4-6); "Wang, as incorporated by Ravi, 
teaches the server adjusts the value of Quantization (Q) to encode the stream. This value of Q is 
adjusted based on a bandwidth level known by the server. Ravi teaches this bandwidth value is 
provided by the client. Adjusting the Q teaches adjusting the sampling rate of the streaming 
data" (page 8, lines 8-12, emphasis added) 

A.2.3 Sampling Rate v. Sampling Time 

It is respectfully submitted that sampling rate is not the same as sampling time . 
Sampling rate is the frequency at which the data is sampled as measured by bytes/second, for 
example. Sampling time is when the part of the streaming data is sampled. The difference 
between sampling time and transmission time is measured by seconds, for example. Sampling 
rate is not part of the claimed limitation . 

The Examiner fails to show that Ravi and Wang disclose adjusting a shift amount in time 
indicative of a difference between a sampling time and a transmission time of a packet at the 
server. 

A.2.4 Wang Fails to Disclose Adjusting Difference Between Sampling Time and Transmission 
Time 

It is respectfully submitted that, in col. 10, lines 21-59, Wang discloses: 

In test step 410 \ secondary closed loop rate control 204 determines whether the 
cumulative bandwidth balance is greater than the upper threshold of the range 
determined in step 404. If the cumulative bandwidth balance is within the desired range, 
processing transfers to test step 414 which is described more completely below. 
Conversely, if the cumulative bandwidth balance is greater than the desired range, excess 
bandwidth is accumulating and processing transfers to step 412 in which secondary 
closed loop rate control 204 decreases Q 114. Accordingly, video image quality is 
increased at the expense of increased bandwidth consumed by subsequent frames. This is 
appropriate since unused accumulating bandwidth is detected and using such bandwidth 
improves the overall perceived quality of the motion video image. In one embodiment, Q 
114 is adjusted 1% for every 3% of the upper threshold that is exceeded by the 
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cumulative bandwidth buffer. After step 412, processing of the current frame by 
secondary closed loop rate control 204 completes. 

In test step 414, secondary closed loop rate control 204 determines whether the 
cumulative bandwidth balance is less than the lower threshold of the desired range 
determined in step 404. If the cumulative bandwidth is within the desired range, 
processing of the current frame by secondary closed loop rate control 204 completes. 
Conversely, if the cumulative bandwidth balance is below the desired range, bandwidth is 
being consumed at too great a rate and processing transfers to step 416 in which 
secondary closed loop rate control 204 increases Q 114. Accordingly, image quality is 
sacrificed to conserve bandwidth used by subsequent frames. Therefore, small excesses in 
consumed bandwidth which are undetected by primary open loop rate control 202 but 
which accumulate over time are detected by secondary closed loop rate control 204 and 
available bandwidth is not exceeded. In one embodiment, Q 114 is adjusted 1% for every 
3% of the lower threshold that exceeds the cumulative bandwidth buffer. After step 416, 
processing of the current frame by secondary closed loop rate control 204 completes. 

The quantization parameter Q used in encoding will affect the amount of encoded data of 
a frame and, therefore, the cumulative data amount to be transmitted. However, adjusting the 
cumulative data amount to be transmitted is different from changing the sampling time. A 
sampling time is when the packet is started to be sampled relative to when the packet is started to 
be transmitted, for example. The sampling time can be moved up or delayed relative to the 
transmission time without changing the encoding resolution. Likewise, the cumulative data 
amount of the packet can be decreased by changing the quantization parameter Q without 
changing the sampling time. 

A.2.5 Ravi and Wang Fails to Anticipate Claim 1 

Ravi and Wang fails to disclose adjusting a shift amount in time indicative of a difference 
between a sampling time and a transmission time of a packet at the server. Ravi and Wang fails 
to disclose adapting in the server the data amount to a reception rate at the client based on said at 
least one parameter, and adjusting in the client packet transfer delay variation based on said 
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adapting, wherein the one parameter comprises a shift amount in time indicative of a difference 
between a sampling time and a transmission time of a packet at the server. 
For the above reasons, Ravi and Wang fails to anticipate claim 1 . 

A. 3 Rejection of Claims 2 and 3 

In rejecting claims 2 and 3, the Examiner further states that Ravi discloses a minimum 
shift amount (decrease bandwidth threshold 512, column 7, lines 35-45; Wang, col. 10, lines 1- 
20) and a target shift amount (delta playtime and shift amount, column 8, lines 36-65). 

Applicant respectfully disagrees. 

A.3.1 Ravi and Wans Fails to Disclose Claim Limitations in Claims 2 and 3 
At column 7, lines 16 to 25, Ravi discloses: 

FIGS. 5 A, 5B, 5C, 5D and 5E, are detailed flowcharts illustrating steps 410, 420, 
430, 440 and 450, respectively, of FIG. 4. In step 410, the performance variables are 
computed. Next, in step 420, the computed performance variables are used to determine 
if it is desirable to decrease the bandwidth, and if so, then in step 430, the bandwidth is 
decreased. If a bandwidth decrease is not desirable, then in step 440, the performance 
variables are used to determine if it is desirable to increase the bandwidth. If a 
bandwidth increase is desirable, then in step 450, the bandwidth is increased. 

In the above paragraph, Ravi discloses the client computer 240 computes the performance 
variable (step 410), including computing playtime and delta_playtime (step 513); decreasing the 
bandwidth (step 430) and sending a reduce_bandwidth message to the server (step 537); or 
increasing the bandwidth (step 450) and sending an increase_bandwidth message to the server 
(step 522). According to Ravi, the term "bandwidth" is synonymous to the " transmission rate " 
(column 6, line 63 to column 7, line 5). 

At column 7, lines 35-45, Ravi discloses: 
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FIGS. 6A and 6B are two halves of a flowchart illustrating the dynamic 
determination of the Upper INC _BW threshold and the DEC _BW threshold, step 512 in 
greater detail In step 612, the difference (Dl) between the Current _Time and the 
previous time the dynamic bandwidth selection method was invoked is computed. In step 
614, the difference (D2) between the times tamp of the last data packet currently in 
playout buffer 366 and the timestamp of the last data packet in playout buffer 366 during 
the previous invocation of the Adjust JBandwidth procedure, is computed. In step 616, the 
difference (D3) between the number of bytes received by the previous invocation and the 
number of bytes currently received (by the current invocation) is computed. 

As pointed out above, Wang only discloses adjusting the quantization parameter Q 1 14 in 
order to adjust the cumulative data amount to be transmitted. Ravi only discloses adjusting the 
transmission rate . Thus, Ravi and Wang does not disclose or suggest adjusting the difference 
between the sampling time and the transmission time . 

At column 8, lines 26 to 65, Ravi discloses: 

FIG. 7 A is a flowchart illustrating the computation of variables Playtime and 
DeltaJPlaytime, step 513, in greater detail. In step 710, Playtime is set to the Duetime of 
the last packet in playout buffer 366. The computation of the Duetime is described in 
greater detail in step 740 below. Client computer 240 determines the change in the 
Playout _BufferJSize (step 720). The DeltaJPlaytime is set to the difference between the 
current Playtime and the Playtime at the previous invocation of the Adjust JSandwidth 
procedure (step 730). Variables Playtime and Delta Playtime provide exemplary absolute 
and relative measures, respectively, of the Playout _Buffer_Size, the number of data 
packet(s) in playout buffer 366. 

FIG. 7B illustrate the determination of the Duetime of a data packet (step 710). 
First, the Base_TS is set to the timestamp of the first packet received by client computer 
240 (step 712). The BaseJTime is set to the time when the first packet was received (step 
716). The TS is set the timestamp of the data packet of interest (step 746). 



1 



944-001.108-1 



In the above paragraphs, Ravi only discloses how the client computer 240 computes the 
Playtime and Delta Playtime (step 513, Figures 5a and 7a) 

A.3.2 Ravi and Wang Fails to Anticipate Claims 2 and 3 

None of the cited passages in Ravi and Wang discloses adjusting the difference between 
the sampling time and the transmission time. Ravi and Wang fail to disclose that the shift 
amount is substantially equal to or greater than the difference . Thus, Ravi and Wang fail to 
anticipate claims 2 and 3. 

Furthermore, claims 2 and 3 are dependent from claim 1 and include further limitations. 
For reasons regarding claim 1 above, claims 2 and 3 are distinguishable over the cited Ravi and 
Wang references. 

A.4 Ravi and Wang Fails to Anticipate Claims 4. 5 and 9 

As for claims 4, 5 and 9, they are dependent from claim 1 and include further limitations. 
For reasons regarding claim 1 above, claims 4, 5 and 9 are also distinguishable over the cited 
Ravi and Wang references. 

A. 5 Ravi and Warn Fails to Anticipate Claims 11-15,17, 19-24 and 26-31 

For reasons regarding claim 1 above, Ravi also fails to anticipate independent claims 11, 
21 and 26, and dependent claims 12-15, 17, 19, 20, 22-24 and 27-31. 

B. 103 Rejection 

At section 4, claims 6-7, 10, 16, 25 and 32-34 are rejected under 35 U.S.C. 103(a) as 
being unpatentable over Ravi, in view of Nilsson et ah (U.S. Patent Application Publication No. 
2005/0172028, hereafter referred to as Nilsson). 

B.l Rejection of Claim 6 

In rejecting claim 6, the Examiner states that Ravi fails to disclose that the parameter 
comprises a shift amount in time indicative clock shift between the server and the client, but 
points to Nilsson for disclosing such feature (paragraphs [0133]-[0134]). 
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B.2 Claim Limitations in Claim 6 

It is respectfully submitted that claim 6 includes the limitations of: 

1) defining in a client in a multimedia streaming network at least one parameter for 
determining a rate adaptation operating range, wherein the streaming network comprises a server 
configured for providing streaming data to the client, the client having a receiver buffer for 
storing at least part of the streaming data to compensate for a difference between data 
transmission amount by the server and usage amount of the streaming data by the client so as to 
allow the client to have sufficient amount of streaming data to play out in a non-disruptive 
manner, and wherein the rate adaption operating range is used for rate adaptation between the 
server and the client; 

2) providing to the server information indicative of said at least one parameter; 

3) adapting in the server the data amount to a reception rate at the client based on said at 
least one parameter; and 

4) adjusting in the client packet transfer delay variation based on said adapting, wherein 
said at least one parameter comprises a shift amount in time indicative of a clock drift between 
the server and the client 

B.3 Nilsson Fails to Disclose Client Sending to Server a Parameter Indicative of Clock Shift 
Amount 

In paragraph [0133], Nilsson discloses: 

To determine the exact amount of data in the client's decoding buffer 41, the 
server also needs to know the time stamp of the data packet that the client is currently 
decoding and presenting. The server 10 calculates this using two assumptions: firstly that 
the client 40 starts decoding immediately after the server 10 sends the first packet; and 
secondly, that the client's clock does not drift significantly from the server's clock in the 
duration of streaming. 

In paragraph [0134], Nilsson discloses: 
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In practice both assumptions have been found to be valid. The client 40 is 
designed to start decoding immediately on receipt of data, and so any error on the 
server's estimated presentation time would result in an underestimate for the amount of 
data in the decoding buffer 41, which as explained above is not a problem. Drift between 
the client's and server's clocks during a typical streaming session is most likely to be 
negligible compared to the amounts of data being buffered. For example, with a 
difference of 100 parts per million, it would take 10000 seconds, or nearly three hours, 
for a drift of one second to occur. In the rare case of a large amount of drift 
accumulating, the client 40 can warn the server 10 by use of a control message, such as 
the one described earlier that is sent for decoding buffer underflow. 

It is respectfully submitted that, in paragraph [0133], Nilsson only discloses that, to 
determine the exact amount of data in the client's buffer, the server also needs to know the 
timestamp of the data packet that the client is currently decoding under the assumption that the 
client's clock does not drift significantly from the server' clock. In paragraph [0134], Nilsson 
discloses that, in the rare case of a large amount of drift accumulating , the client can warn the 
server by use of a control message, such as the one described earlier that is sent for decoding 
buffer underflow . 

According to Nilsson, in case of decoding buffer underflow , the server is notified of the 
buffer underflow so that the server will send packets as quickly as possible (paragraph [0126]- 
[0127]). Furthermore, even if the server knows what the timestamp of the data packet the client 
is currently decoding, the server does not know the clock drift between the server and the client. 
While the server may be able to estimate the cumulating data amount in the client from the 
timestamp of the data packet the client is currently encoding, the server may not be able to know 
the exact cause of data cumulating in the client. Nevertheless, Nilsson fails to disclose providing 
to the server information indicative of at least one parameter defined in the client, wherein said at 
least one parameter comprises a shift amount in time indicative of a clock drift between the 
server and the client. 



B.3.1 Ravi. Warn and Nilsson Fail to Render Claims 6. 7, 10, 16, 25 and 33-34 Obvious 
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For the above reasons, Ravi, in view of Nilsson, fails to render independent claim 6 
obvious. 

For the same reasons, Ravi, in view of Nilsson, fails to render independent claim 32 and 
dependent claims 7, 10, 16, 25 and 33-34 obvious 
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CONCLUSION 



Claims 1-7, 9-17, 19-34 and 36 are allowable. Early allowance of all pending claims is 
earnestly solicited. 



WARE, FRESSOLA, VAN DER SLUYS 
& ADOLPHSON LLP 
Bradford Green, Building 5 
755 Main Street, PO Box 224 
Monroe, CT 06468 
(203) 261-1234 



Respectfully submitted, 




Kenneth Q. Lao 
Registration No. 40,061 
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